home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0131.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  3.2 KB  |  72 lines
  1. On Fri, 02 Jul 93 09:43:19 BST, A.Grant@ucs.cam.ac.uk wrote:
  2. > On the contrary, sending through IMAP could have a great benefit if the
  3. > IMAP server is co-located with the client (or to be precise, if the IMAP
  4. > server is not located significantly further away than the nearest available
  5. > SMTP server), in that it would not require the sender's authenticity to be
  6. > established for each submitted message.
  7.  
  8. Access authentication is not the same thing as posting authentication.  Note
  9. that IMAP already has an anonymous access mode.
  10.  
  11. To get authenticated e-mail, you need authenticated data (e.g. PEM) and/or
  12. authenticated transport.  Shoehorning transport into an access protocol such
  13. as IMAP, or the use of kludges like RFC-931, are band-aids that at best give
  14. the illusion of solving the problem.  It is not the right solution to the
  15. problem of forged e-mail.
  16.  
  17. There is also a performance problem, even on a local network.  It ties up the
  18. IMAP stream while message delivery is going on.  Sometimes it takes several
  19. minutes, particularly with dialup IP links, for the message to be delivered
  20. over the network.  Shoehorning delivery into IMAP precludes background
  21. delivery of mail.
  22.  
  23. > > If the IMAP
  24. > > server is remote (or in a foreign country), sending through IMAP is
  25. > > potentially a horribly slow (and expensive!) operation.
  26. > So?  Nobody would be forced to use it.
  27.  
  28. I can guarantee that most MUA implementors will implement only one way of
  29. sending mail.  Whatever way is the ``encouraged way'' will become the forced
  30. way.  The POP world has discovered this, with clients that use optional
  31. extentions and don't work with the reference implementations.
  32.  
  33. > Anyway, if I was in a foreign
  34. > country for a long time I would be just as likely to want to get my home
  35. > IMAP server to forward my messages automatically to an IMAP server closer
  36. > to me.
  37.  
  38. I am a frequent traveller, and I object to having to forward my mail every
  39. time I am out of the country for a week.  Why should I, when I have this
  40. wonderful IMAP that is carefully designed to work well over slow links?
  41.  
  42. Why shouldn't I keep my mail on a foreign IMAP server on that IMAP server if I
  43. want.  Perhaps that data is there because it is primarily useful there, and
  44. not all forwarded to my local machine.
  45.  
  46. Why should my IMAP mail reading be blocked while a message I just composed is
  47. being sent overseas, when I could drop it off at a local SMTP server in the
  48. background?
  49.  
  50. The whole point is, with access and delivery functionality separate, the user
  51. has the choice.  With them shoehorned into the same protocol, there is no
  52. choice.
  53.  
  54. I agree that it sounds nice and easy, but it's only suitable in the most
  55. simple cases and has many possible bad side effects that can not be prevented
  56. easily.
  57.  
  58. Why not lobby in the IETF-SMTP group to have authenticated transport?  That
  59. is, after all, what you really want; the credentials required to access mail
  60. are not necessarily the same as the credentials to post mail.
  61.  
  62. > And I would want a
  63. > "submit from message store" function so that I could say "Fred, I'm out
  64. > of the country - please could you deal with the attached 100MB piece of
  65. > video mail".
  66.  
  67. MIME provides a mechanism of doing this now, with the external reference
  68. functionality.
  69.  
  70.  
  71.  
  72.